home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.078 < prev    next >
Encoding:
Text File  |  1990-04-03  |  4.8 KB  |  96 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6. Apple IIGS
  7. #78:    Bank Alignment and Memory Management
  8.  
  9. Written by:    Matt Deatherage                                     March 1990
  10.  
  11. This Technical Note discusses the way the Memory Manager deals with requests 
  12. for memory that is already in use, and why this can be really annoying.
  13. _____________________________________________________________________________
  14.  
  15. The Memory Manager is a sophisticated software module that provides the 
  16. framework for the allocation, moving, management, and disposal of blocks of 
  17. memory; however, it's not magic.
  18.  
  19. When you ask the Memory Manager for a block of memory and it's not immediately 
  20. allocatable, the Memory Manager starts through the procedure for purging, 
  21. compacting, and calling out-of-memory (OOM) queue routines until, at the end 
  22. of its rope, it finally gives up and returns error $0201.  The exact procedure 
  23. is repeated below, taken from Volume 3 of the Apple IIGS Toolbox Reference.  
  24. Note that each successive step is only taken if, after the previous step, the 
  25. requested memory still isn't available.
  26.  
  27.   1.  Calls each OOM queue routine until either all routines have been 
  28.       called or until one OOM queue routine reports that it has freed 
  29.       enough memory to satisfy the request.
  30.   2.  Compacts memory.
  31.   3.  Purges all level 3 handles.  If this frees enough memory, 
  32.       compaction occurs.
  33.   4.  Purges all level 2 handles.  If this frees enough memory, 
  34.       compaction occurs.
  35.   5.  Purges all level 1 handles.  If this frees enough memory, 
  36.       compaction occurs.
  37.   6.  Calls each OOM queue routine again until all have been called or 
  38.       until one OOM queue routine reports that it has freed enough 
  39.       memory to satisfy the request.
  40.   7.  Gives up and returns error $0201.
  41.  
  42. This strategy works pretty well--as long as the request is for a block of 
  43. memory wherever it fits.  If someone has asked the Memory Manager for memory 
  44. at a specific address, things get stickier.
  45.  
  46. Suppose that you've asked the Memory Manager for a handle starting at the 
  47. beginning of bank 2, and that something else (i.e., the ProDOS FST) is already 
  48. using that memory.  The Memory Manager notices that the handle isn't 
  49. immediately available, so it starts going through the listed procedures.  
  50. Since the handle for the ProDOS FST is neither purgeable nor movable and GS/OS 
  51. isn't likely to give it up in an OOM queue routine, the request fails and the 
  52. Memory Manager returns error $0201.
  53.  
  54. However, the Memory Manager went through all the steps listed to get to the 
  55. seventh step, the error.  The Memory Manager has no way to know that one of 
  56. the OOM queue routines isn't going to give up that particular handle and allow 
  57. the request to be fulfilled.  The OOM queue routines cannot know themselves, 
  58. since they are only told how much memory is needed, not where it has to be.  
  59. Therefore, whenever the Memory Manager returns error $0201, all purgeable 
  60. handles have been purged.
  61.  
  62. This is particularly annoying to loaders.  OMF supports a "bank-aligned" 
  63. attribute for load segments, and the loaders ensure that such segments are 
  64. loaded at the beginning of some bank or another.  The Memory Manager does not 
  65. have a "bank-aligned" attribute for handles, so the loaders have to do these 
  66. things themselves.  They do this by asking for a handle of the appropriate 
  67. size at the beginning of bank two.  If this fails, the loaders try again with 
  68. bank three, then bank four, and so on through the end of memory.
  69.  
  70. Since some part of GS/OS is almost always occupying the memory at the 
  71. beginning of bank two, which is where the loader first attempts to load a 
  72. bank-aligned segment, the presence of such a segment in a load file virtually 
  73. guarantees that all purgeable handles are purged when the file is loaded.  
  74. This kicks out dormant applications and zombie-state tool sets, among other 
  75. things, requiring they be loaded from disk again when needed.
  76.  
  77.  
  78. Summary
  79.  
  80. The general recommendation against asking for specific blocks of memory is 
  81. well-known to most developers; the reasons outlined above simply add fuel to 
  82. the fire against such programming practices.  What isn't as widely known is 
  83. that having a bank-aligned load segment in a load file almost always causes 
  84. everything purgeable to be purged, and could also cause OOM queue routines to 
  85. dispose of handles when there really isn't any kind of memory shortage.
  86.  
  87. Apple advises developers to carefully consider the advantages and 
  88. disadvantages of bank-aligned segments before including one in a load file.
  89.  
  90.  
  91. Further Reference
  92. _____________________________________________________________________________
  93.   o  Apple IIGS Toolbox Reference, Volumes 1 and 3
  94.   o  GS/OS Reference
  95.  
  96.